BBS Toolkit/BBS Toolkit.iso/windows/msk312.zip/KERMIT.BWR

Text File | 1992-09-29 | 64KB | 1,257 lines

File MSK312.BWR        MS-DOS KERMIT 3.12 "BEWARE FILE"         September 1992

             BUGS, LIMITATIONS, AND HINTS

This file applies to both versions 3.11 and 3.12 of MS-DOS Kermit for the IBM
PC and PS/2 families and compatibles.  If you have problems with MS-DOS
Kermit, please read this to find out the status of the problem.  It might be
known already, and a workaround listed here.  Problems in 3.11 that are fixed
in 3.12 are noted.

The user manual for MS-DOS Kermit 3.11 is the book "Using MS-DOS Kermit",
Second Edition, by Christine M. Gianone, published by Digital Press, Bedford,
MA (1991), order number EY-H893E-DP.  Call 1-800-344-4825 (toll free, USA) to
order, or order by mail from Columbia University.  Use this file plus the file
MSR312.UPD as a supplement to the book.

  Certain features were added to the dialing directory and the TCP/IP
  support after press time for the second edition of the book.  For
  greater details about these features, see the MS-DOS Kermit help file,
  KERMIT.HLP or MSKERM.HLP.  For TCP/IP, also see the section at the
  end of this file.

MS-DOS Kermit 3.11 has been successfully tested with PC-DOS 2.0, 3.0, 3.30, 4.0
and 5.0 on a wide variety of IBM PCs, XTs, PC/ATs, PS/2s, and compatibles.  DOS
2.0 or later is required for basic operation, and 3.30 or later is required for
certain features such as code page switching.

Building version 3.12 from source code requires Microsoft MASM and C 6.0 or
later.

Please report problems via e-mail to [e-mail] or to
[e-mail], or call [phone], or write to Kermit Distribution,
Columbia University Center for Computing Activities, 612 West 115th Street,
New York, NY 10025, USA.

PROBLEMS CORRECTED BY PATCHES IN MSKERMIT.PCH

NOTE:  All the problems listed in this section are corrected in version 3.12.

Some bugs that surfaced after the release of version 3.11 are correctable by
runtime patches in the file MSKERMIT.PCH.  Put this file in the same directory
as your MSKERMIT.INI file, and the patches will be installed automatically each
time you start Kermit.

Patch #1 (optional): Supply a different video mode for the Orchid Designer
Professional VGA board when switching to 132 columns.  As distributed, this
patch is commented out.

Dump screen via Ctrl-]F turns on LOCAL-ECHO. Corrected by Patch #2.

Problem with cursor indexing in scrolling region setup.  Fixed by Patch #3.

Problems with matching curly braces in commands.  Fixed by Patch #4.

Various reports requested by VT320 escape sequences from the host are not
furnished.  Fixed by Patch #5.

Transparent printing problem: MS-DOS Kermit does not properly respond to
CSI 4 i to terminate transparent printing when the CSI is sent in 8-bit form.
Fixed by Patch #6.

Inability to transfer files on SET PORT TCP/IP connections when PARITY is
EVEN or MARK.  Fixed by Patch #7.

VT220/320 DEC User Definable Keys, downloaded via escape sequences from the
host, were being defined incorrectly.  Fixed by Patch #8.

The new release (2.2/R8) of Interconnections Inc's TES program crashes Kermit
and requires the PC to be rebooted.  Patch #9 is a workaround for this problem.
The TES bug also prevents correct reception of 8-bit characters.  Temporary
workaround: tell the host not to send 8-bit data (e.g. SET TERMINAL /NOEIGHT in
VAX/VMS).

USING MS-DOS KERMIT ON LOW-END PCs

Original 4.77 MHz PCs (PC, PC/XT) operate at lower processing speed than
modern PC models, and can not support high communication speeds (9600 bps,
19200 bps, 38400 bps, depending on the exact configuration), unless both
MS-DOS Kermit is configured to use XON/XOFF software flow control or RTS/CTS
hardware flow control, and the computer or device with which MS-DOS Kermit is
communicating also supports, and is configured to use, the same kind of flow
control.

It is possible to boost the performance of a low-end PC by installing a 16550
UART in place of the original 8250 if your serial board has a socketed
(removable) UART chip.  The 16550 incorporates an internal hardware buffer to
reduce the amount of interrupts that must be serviced by MS-DOS Kermit.
MS-DOS Kermit fully supports the 16550 UART's buffering capabilities.

MS-DOS 5.0

Reportedly, Kermit can lose incoming characters at high speeds (19200, 38400,
etc, depending on CPU model).  DOS 5.0's new memory management functions might
be causing interrupts to be lost.  If the serial port data-ready interrupt is
not delivered to Kermit, Kermit never knows that a character has arrived and
therefore does not read it.  This problem has been reported by some users,
while most other users report no problems at all operating at high speeds
with DOS 5.0.

MICROSOFT WINDOWS, DESQVIEW, OS/2, ETC

Although MS-DOS Kermit can work in these environments, and even takes advantage
of many of their features, it does not have a "graphical user interface".  You
still have to type commands to the MS-Kermit> prompt or execute them from
command files with the TAKE command.

OS/2 1.x...

Under OS/2 1.3 and earlier, MS-DOS Kermit only runs in full-screen mode.
Under 1.x of OS/2, the serial port must first be conditioned by the command:

  SETCOM40 COM1=ON

OS/2 2.0...

MS-DOS Kermit can run in a window of OS/2 2.0.  Under OS/2 version 2.0,
Kermit's flow control reportedly has no effect because OS/2 itself is doing
the buffering.  You can configure OS/2 to handle flow control itself by
adding a command like the following to your STARTUP.CMD file:

    MODE COM1 XON=ON          (for XON/XOFF software flow control)
or:
    MODE COM1 RTS=HS OCTS=ON  (for RTS/CTS hardware flow control)

If your PC's communication port is a 16550A[NF] UART serial communication
adapter (as is standard on the PS/2), it has a built-in buffer to improve
performance.  To enable use of the 16550's buffering capability, add BUFFER=ON
to your MODE command:

    MODE COM1 XON=ON BUFFER=ON         (for XON/XOFF software flow control)
or:
    MODE COM1 RTS=HS OCTS=ON BUFFER=ON (for RTS/CTS hardware flow control)

IDLE_SENSITIVITY should be set to 0 and IDLE_DETECTION_TIME should be 100 to
reduce the jerkiness of DOS sessions.

By all accounts, massive amounts of memory (at least 8MB, and the more the
better) are required for successful operation of MS-DOS Kermit or ANY
communications software written for DOS in order to prevent the software from
being swapped out while characters are arriving at the serial port.

On OS/2 systems with small amounts of memory, characters are can be lost
during terminal emulation and file transfer, especially at high communication
speeds.  It is also reported that other commands, particularly script
programming and macro commands which allocate memory dynamically, fail in
bizarre ways.  These problems have been reported to IBM and hopefully a
solution will be found.  Meanwhile, here are some suggested workarounds:

 1. Install more memory in your PC, bringing it up to 8MB or more.
 2. Remove the line IFS=HPFS.IFS from CONFIG.SYS.
 3. Run Kermit at a lower communication speed.
 4. Use the MODE command to have OS/2 perform the desired type of flow control.
 5. Configure Kermit to use the minimum amount of memory for rollback
    screens, etc. ("SET KERMIT=ROLLBACK n" DOS environment variable).

IBM suggests running Kermit in a true DOS 5.0 Session instead of the VDM to
allow direct hardware access, but reportedly this does not help because of
problems in OS/2's COMM.SYS and VCOMM.SYS drivers.  (Perhaps it helps if these
drivers are not loaded).  The VCOMM.SYS driver is certified by IBM to work at
speeds up to 2400 bps, but reportedly it has trouble even at this low speed.

Other hints for those who are experiencing buffer overruns or other data loss:
For file transfer, use small packet sizes and a window size of one.  During
terminal emulation, avoid host-initiated printing.

TCP/IP (and presumably other networks supported by MS-DOS Kermit) cannot be
used with OS/2.  OS/2's network interface, the Communication Manager, is
totally different from the methods (such as Packet Drivers) known to Kermit.
If Novell provides a Virtual ODI Driver (VODI.SYS?) for OS/2, MS-DOS Kermit
3.12 or later should be able to operate in this environment with its new
built-in ODI support.

WINDOWS...

You can't run Kermit in a Microsoft Windows 3.0 window except on a 386-class
machine in running Windows in Enhanced Mode, which generally requires that
your PC have at least several megabytes of main memory.

Under Windows 3.0 Real or Standard mode, you can use still use MS-DOS Kermit
as a full-screen DOS application.  Kermit works in a window on all PCs (if
they have enough memory) under Windows 2.0.

Reportedly, a third-party communication port driver (such as TurboComm) might
be needed to run Kermit at speeds greater than 9600 bps under Windows 3.0.  A
16550a UART helps too, for its FIFO buffering.  Other reports indicate that
high speed operation is possible after all, and suggest looking at the Windows
files SYSIN*.TXT for information about SYSTEM.INI settings related to
communication ports, particularly COMxBuffer and COMBoostTime.  Still other
reports say that Kermit runs fine in a window at 19200 bps without losing any
characters, as long as a good flow control method (such as RTS/CTS) is in
effect.  The real answer is a combination of software, BIOS, machine
architecture, serial port hardware, which drivers and TSRs are loaded, system
load, and Windows settings.

When running Kermit in two windows at once, one on COM1, one on COM2, Windows
complains that both applications want to access COM1.  To make sure that COM1's
IRQ 4 is not touched when starting COM2 (part of the "find the IRQ" test),
specify the COM2 port parameters explicitly as SET COM2 \x2f8 3 (standard port
address and IRQ for COM2) to make Kermit skip the test.

The use of COM3 and COM4 under Windows is problematic, but most users report
success after finding the right "SET COMx <address> <irq>" command.

When running MS-DOS Kermit under any version of Windows, specifying a ",P" at
the end of a serial port setting in WIN.INI or in a MODE command can cause loss
of characters from the serial port.  Remove the ",P" from the setting.

WINDOWS AND TCP/IP...

To use Kermit's TCP/IP support under Windows 3.0, you either must set up the
KERMIT.PIF file to "Lock Application Memory" (Enhanced-Mode Advanced options
screen), or else run the WINPKT "shim" in addition to (and after) your packet
driver.  WINPKT should be given a lower software interrupt number than your
packet driver, for example (using a Western Digital Ethernet board):

  WD8003E 0x61 0x7 0x280 0xca00
  WINPKT 0x60 0x61
  IPX
  NETX

The order is important: start the packet driver first at interrupt 0x61
(or higher).  Then start WINPKT, telling it to use interrupt 0x60 to talk to
application software, and 0x61 to talk to the actual packet driver.  After
loading WINPKT, you can optionally load Novell or other
packet-driver-compatible network software.

Only one copy of MS-DOS Kermit can make a network connection at one time under
Windows.

Here is a PIF configuration for Kermit that has proven successful for TCP/IP
operation in a Windows 386 Enhanced-Mode window:

  Video Memory:    High graphics
  Memory:                  320  640
  Display:                 Windowed
  Execution:               Background
  Close Window on Exit
  Foreground/Background:   100 or 150
  Detect Idle Time
  Lock Application Memory (or don't lock application memory if WINPKT loaded)
  Monitor nothing ports
  Emulate Text Mode
  Retain Video Memory

DESQVIEW and DESQVIEW/X ...

Users of DESQview set "Optimize Communications" in the Advanced menu to "No".

DESQview/X reportedly requires that the serial port be configured to
"optimize" to prevent Kermit from losing characters.  Network connections
(TCP/IP over a packet driver or ODI) within an X window of DESQview/X
apparently do not work.


INCOMPATIBILITIES BETWEEN MS-DOS KERMIT 3.11 and 3.00/3.01:

In version 3.11, "O" is not a sufficient abbreviation for OUTPUT because of
the new OPEN command.  If you have a script with "O" commands in it, it will
fail.  If you have exactly one macro defined that starts with "O", it is
executed instead.  Change abbreviations of OUTPUT from "O" to (at least) "OU".
In version 3.12, "O" is accepted as a special abbreviation for OUTPUT.

Macro arguments are now "stacked", saved at each macro entry and restored upon
exit, so calling macro B from within macro A no longer destroys macro A's
arguments.

Macro definitions in 3.11 can be longer than before.  Long macros that work in
3.11 won't necessarily work in earlier releases.

The new macro argument \%0 now holds the name of the macro.

The REPLAY command allows screen rollback, dump, print, etc.  At the end of the
replay file, use regular terminal emulation keys (PgUp, Ctrl-End, PrintScreen)
to invoke these functions, and use Alt-X, Ctrl-]C, or Ctrl-C to get back to the
prompt.  Previously, any keystroke would return to the prompt.

If an INPUT command is interrupted by pressing any key, the status is set to
FAILURE, just as if the command had timed out.  If you need to know whether an
INPUT failed because it timed out or was interrupted, use a technique like
this:

  SET ALARM 30
  INPUT 30 Login:
  IF SUCCESS GOTO OK
  IF ALARM ECHO INPUT Timed out
  IF NOT ALARM ECHO INPUT Interrupted from keyboard

ECHO no longer requires a \13 on the end.  It supplies both CR and LF.

The WRITE command, introduced in version 3.00, no longer accepts "objects"
like DATE, TIME, etc.  Now it is more like an ECHO command that includes a
destination specifier: WRITE SCREEN, WRITE SESSION, etc.  The argument in all
cases is a line of text.  This text may contain any kind of backslash codes or
variables, including the new (to version 3.10) built-in \v(xxx) variables like
\v(time), \v(date), etc.  Old-format WRITE commands will produce undesired
results.  For example WRITE SCREEN TIME FOO will print "TIME FOO" on the
screen rather than something like "12:34:56 FOO".

BYE, FINISH, or LOGOUT commands that fail (e.g. because the remote server has
these operations disabled) no longer behave as if they had succeeded.

Text and graphics screens can now have separate colors.

Host-generated autoprint sequences work differently.  In version 3.01 and
earlier, MS-DOS Kermit copied characters to the printer as they arrived,
regardless of the screen dimensions.  In version 3.10 and later, Kermit's
action follows that of a real VT terminal: it waits until the cursor moves off
the line with a linefeed or formfeed, or the line wraps.  If your screen does
not support 132 columns, Kermit wraps long lines -- even those destined for the
printer during autoprint sequences -- at 80 columns.  If you need to direct
long lines to your printer under these circumstances, use transparent print
instead, or else LOG SESSION PRN and then print the log.

The Alt-minus key no longer "toggles" among all of Kermit's terminal types.
As of version 3.11, Alt-minus switches between the Tektronix graphics screen
and the text screen for the current text terminal type (e.g. VT320).

DIALING

The DIAL command and dialing directory have been totally redone for MS-DOS
Kermit 3.11.  See KERMIT.HLP (MSKERM.HLP) for a description.  If you need to
dial a non-Hayes compatible modem, write a dialing script for it, and change
the definition of the "_modem" variable in MSKERMIT.INI.  See MSIROLM.SCR for
an example: a dialing script for the IBM/Siemens/Rolm CBX.

SERIAL COMMUNICATIONS

On IBM PCs and PS/2s with IBM asynchronous adapters, Kermit can be used at
speeds up to 57600 bps under DOS (under Windows or DesqView, the maximum speed
is probably lower).  115200 bps works only with a very short shielded cable,
and the async adapters of the two machines in perfect tune.  Some VAX serial
port interfaces are out of tolerance at 19,200 bps and faster.

If your speed is set too high, the symptom might be lost or garbled characters
or graphics images on the screen, or data-overrun beeps.  Normally flow control
prevents these problems so use it if you can.  Printing while in CONNECT mode
needs flow control to be active.

MS-DOS Kermit does not monitor the communication line for carrier loss during
terminal emulation or file transfer.  You can SHOW MODEM or SHOW COMMUNICATIONS
to inquire about CD, DSR, and CTS.  The script command WAIT permits sensing
carrier presence in a script program.

The SHOW MODEM and WAIT commands work right only if your modem or other
communication device is configured to raise and lower the DSR, CTS, and CD
signals appropriately, and the cable that connects your PC to the modem passes
these signals through.  For some modems, the factory setting is to always keep
CD on, even if there is no connection.  Consult your modem manual.

For RS-232 devices, the HANGUP command (and Ctrl-]H in CONNECT mode) works
only if the cable that connects your PC to the communication device passes the
DTR signal through, and if the communication device itself is configured to
hang up or otherwise terminate the connection when the DTR signal is lowered
by the PC.  For some modems, the factory setting is to ignore DTR transitions.
Consult your modem manual.  NOTE: in version 3.11, the HANGUP command turned
off DTR for about 1/2 second and then turned it back on again.  In version
3.12, the HANGUP command turns off DTR until the next time you issue a command
that accesses the serial port.

When communicating across some network pathways, the longest burst of
information tolerated from the PC can be rather short.  For example, the LAT
path with SET PORT DECnet has a limit of 256 bytes and the SET PORT TES path
has a limit of 512 bytes in a burst.  Longer bursts can cause the network
software to drop the connection.  This is important when sending files, and if
sliding windows are active, the sum of all the packets in the window (packet
length times the number of window slots) must be shorter than the above limits.
This is not a Kermit problem.

TERMINAL EMULATION

Kermit's VT320/340 emulator lacks the following features:

 . Smooth scroll
 . Downloadable soft fonts
 . ReGis graphics (VT340/330)
 . Dual sessions in split screens (VT340/330)
 . Local screen editing and block transmission (for security reasons)
 . ENQ/Answerback (also for security reasons)
 . True double height/width characters (these are simulated)
 . Selective erasure (as a character attribute, a formatted screen item)
 . Many of the exotic and rarely used features of the DEC VT340/330
   series: mostly formatted screen and graphics operations highly specialized
   to DEC hardware.

On certain "national keyboards", like the German keyboard, Kermit's normal
escape character, Ctrl-] (Control-Rightbracket) does not appear to work.  This
is because IBM changed the way certain control characters are typed on these
keyboards.  On the German keyboard, Ctrl-] is produced by holding down the Ctrl
(Strg) key and pressing the + (plus) key.  MS-DOS Kermit has no way of knowing
this, and continues to display the escape character as "^]".

Kermit does not work with certain Swedish keyboard drivers because of a bug
in the keyboard driver.  Workaround: use a different keyboard driver.
Reportedy there are several different Swedish keyboard drivers available.

If VAX/VMS thinks you have a VT220 or VT320, it sends 8-bit control sequences.
Kermit does not understand them unless you SET TERMINAL BYTESIZE 8.  The
symptom is the appearance of fragments of escape sequences on the screen and
wrong cursor positioning, and possibly fractured tab settings, particularly
during EVE sessions.  You can prevent VMS from sending 8-bit control sequences
(if you really do not have an 8-bit connection) by giving the VMS command SET
TERMINAL /NOEIGHT.  For VAX/VMS, you should also use Xon/Xoff flow control in
both directions (SET TERM /TTSYNC /HOSTSYNC on VMS).

In VT100/200/300 emulation on the IBM PC family, receipt of ESC [ 4 m (turn on
underscore) results in reverse video rather than underscore on IBM CGA, EGA and
other color displays.  IBM display adapters have one less attribute than DEC
monochrome terminals, and in addition the two systems intensify dots
differently (IBM does foreground/character dots only, whereas DEC can
illuminate any dot).

SET TERMINAL COLOR 1 [3xx 4xx] (used to make the foreground color bright), if
issued when SET TERMINAL SCREEN REVERSE is in effect, reverts to normal video.

If certain incomplete escape sequences (e.g. Operating System Command) are
received during terminal emulation, Kermit can hang waiting for the string
terminator that never comes, usually because of noise on the communication
line.  Reset the terminal emulator by pressing Alt-= (Alt-equals), the default
key for \Kreset.

Kermit does not support 132-column mode on the IBM monochrome adapter, CGA,
MCGA, or EGA.  However, if your display adapter handles 132 columns in text
mode, and Kermit knows how to control it, Kermit can switch automatically
between 80- and 132-column mode upon host command or SET TERMINAL WIDTH { 80,
132 }.  Otherwise you can provide external commands for changing the width in
the files COLS80.BAT and COLS132.BAT.  Kermit does not support other widths
(except, to a certain extent, 40).

Kermit assumes 25 screen lines but can adapt to other lengths if it knows how
to get this information from the video adapter.  There still might be some
confusion about screen length when switching between text and graphics modes,
or between 80 and 132 column mode, or escaping back from CONNECT mode, due
primarily to lack of reliable or consistent information from the many different
kinds of video adapters.

The following video boards are directly controllable by Kermit for changing
screen width:

  ATI EGA and VGA Wonder
  AST, Dell, and other boards based on Western Digital VGA boards
  AT&T / Olivetti
  Everex Viewpoint EV-659, FVGA-673, EV-678, Micro Enhancer Deluxe
  IBM XGA
  Paradise AutoSwitch EGA Mono
  Paradise Professional
  Paradise VGA Plus 16 (ROM BIOS 003056-xxx firmware)
  Paradise VGA Plus (ROM BIOS 003056-xxx firmware)
  Paradise VGA Professional (ROM BIOS 003056-xxx firmware)
  Paradise VGA1024
  STB VGA/EM (Tseng TVGA)
  STB VGA/EM Plus (Tseng 4000), VGA/EM-16, VGA/EM-16 Plus
  Tseng Labs EVA board with 132-column kit installed
  Tseng Labs UltraPAK mono/Hercules with 132 column modes
  Video 7 Vega Deluxe with 132X25.COM driver installed and Video 7 VGA

For other boards, create COLS80.BAT and COLS132.BAT files.  If your video
board and monitor can't do 132 columns in text mode, neither can Kermit.

If you have a monitor with fixed horizontal frequency but a video adapter that
Kermit knows how to switch into 132 column mode, you will see only garbage on
your screen whenever Kermit switches to 132 columns.  There is no way to tell
Kermit to ignore "switch to 132 columns" commands.  If you buy a
132-column-capable video adapter, be sure you have a compatible monitor.

To get properly formatted screens during terminal emulation, be sure to inform
the remote host of your screen width and length.

So that key translation and macros can work on both IBM and non-IBM compatible
PCs, Kermit uses the system BIOS to obtain key scan codes.  But the IBM BIOS
does not produce scan codes at all for certain keys, and may produce duplicate
scan codes for others.  Num Lock, Scroll Lock, Pause are examples.

When you PUSH to DOS (including when you use Kermit's RUN command), and you
have XON/XOFF flow control enabled, Kermit sends an XOFF (Ctrl-S) to the host
when you leave, and XON (Ctrl-Q) when you return.  This prevents data
transmitted by the host from being lost.  However, if you do this while using
the EMACS text editor on the host, the Ctrl-S will be interpreted as a Search
command, and the Ctrl-Q as a Quote command.  When you return to EMACS, type
several Ctrl-G's to get back to normal.

Similar comments about sending Xoff and Xon apply when Kermit is commanded
to change its screen size between 80 and 132 columns.

Session logging can be turned on using the LOG SESSION command, and it can
be toggled on and off during terminal emulation by using whatever keys are
associated with the verbs \Klogoff and \Klogon.  One user stated the
requirement to enable a session log, but to have it initially turned off.
This can be done as follows (using the F1 and F2 keys as examples):

  SET KEY \315 {\Kloginit}  ; F1 to turn on log
  SET KEY \316 \klogoff     ; F2 to turn log off
  DEFINE loginit log session, set key \315 \klogon, define loginit, connect

To log your session to a printer, add the word PRN after "log session" in
the third line above.

The session log is written to disk by DOS.  The frequency with which DOS
updates this file is governed by the BUFFERS= line in your CONFIG.SYS file (see
your DOS manual).  If you allocate a large number of buffers in CONFIG.SYS,
disk operations occur infrequently and this improves performance.  If you need
to have the session log updated more frequently to minimize the loss of data
when there is a power failure, you can do this (at the expense of efficiency)
by allocating a smaller number of buffers in CONFIG.SYS.

GRAPHICS TERMINAL EMULATION

If your display adapter lacks sufficient memory (as do CGA and the early 64K
EGA boards), then when you switch away from a graphics screen, or type the
connect-mode escape character (Ctrl-]), the graphics image is lost.
Furthermore, certain graphics images may be overlaid with vertical stripes on
small (64K) EGA systems.

PS/2 Model 25 and 30 MCGA adapter is used in low-resolution CGA mode by
default; images may be elongated or truncated.  Hi-resolution graphics can be
done (as of version 3.11) via SET TERM GRAPHICS VGA, but the PC might not be
able to keep up at speeds above 9600 bps.

When you type the escape character (normally Ctrl-]) while in Tektronix
graphics mode, the screen goes back to text memory.  Then when you type the
argument character, the graphics screen reappears (unless the argument was C or
P).  Ctrl-]F will not file the graphics screen, but rather the text screen,
because that's the screen that's showing after type the Ctrl-] key.  To file
the graphics screen (in TIFF format), use \Kdump (normally on Ctrl-End).

You can't dump the Tektronix screen while the GIN-mode crosshair cursor is
active; Kermit's keyboard translator is not active.  Key strokes (of regular
typewriter keys) or mouse actions are used to transmit the crosshair
coordinates.  If you press a non-typewriter key, Kermit just beeps.

Kermit does not emulate a particular kind of color graphics terminal, such as a
DEC ReGIS display or a Tektronix 41xx or 42xx series.  However, it can be used
for color graphics by mixing ANSI color-setting escape sequences with Tektronix
or Sixel commands.  This requires graphics software vendors adding support for
MS-DOS Kermit graphics to their packages (so far, WordPerfect Corp has done
this for their host-resident products).  There is at least one ReGis-to-Sixel
converter on the market: RETOS, a DEC product for VAX/VMS.

Problems may occur when using Kermit with host-resident (VAX/VMS) versions of
WordPerfect because the color palette report sent upon request of WordPerfect
is very long. If the host is not configured properly, parts of the report will
be lost because of overruns on the VMS side.  SET TERM /HOSTSYNC and /TTSYNC
are required for WP/VMS.  Even then intervening communication boxes (e.g.
terminal servers) can become overloaded with the 200++ byte response.

PRINTER SUPPORT

(Shift-)Printscreen can cause the PC to hang if there is no attached printer.
This is a BIOS feature, Kermit never receives the command.  If this happens
during terminal emulation, try pressing Alt-= (hold down Alt and press the "="
key) several times to reset the terminal emulator.

Serial printers are not directly supported.  Kermit does not do flow control
between itself and a serial printer.  To use a serial printer effectively, you
must have a driver for it that takes care of flow control, such as MSPSPD,
available on the MS-DOS Kermit Utilities and Technical Documentation diskette.

Transparent printing starts when the host sends the sequence ESC [ 4 i and
stops when the host sends ESC [ 5 i.  All characters, including escape
sequences, that arrive at the port are passed directly to the printer without
translation (but the parity bit is stripped if Kermit's parity is not NONE).
If character translation is desired, or it is desired not pass screen-control
escape sequences to the printer, use Autoprint rather than Transparent print
(ESC [ 0 i, ESC [ ? 4 i, ESC [ ? 5 i).  In that case, characters are translated
to the current IBM code page.  If your printer doesn't support your IBM code
page, you need an external utility to translate from the PC code page to the
printer's character set.  You can use SET PRINTER xxxx to capture Transparent
print or Autoprint data into a file.

INTERNATIONAL CHARACTER SETS

In MS-DOS Kermit 3.01 and later, SET TRANSLATION INPUT has been extended to
work with character sets in which the C1 range (80h-9fh) contains graphic,
rather than control, characters, but only if you SET TERMINAL CHARACTER-SET
TRANSPARENT.

MS-DOS Kermit 3.01 changed the strategy used by SET TRANSLATION INPUT and
which is described in the first edition of "Using MS-DOS Kermit".  In version
3.00 and earlier, the command worked like this:

  SET TRANSLATION INPUT \xxx \yyy

where \xxx is the code for the character received at the communication port,
and \yyy is the code for the character to display on the screen.  In version
3.01 and later, \xxx is the code for the character that would be displayed on
the screen in the current code page after normal translation, rather than the
untranslated character that arrives at the port.  Example: modifying the
built-in Swedish character set to show selected character values as ASCII
rather than Swedish characters (using PC code page 437) is now done like this:

  SET TERMINAL CHARACTER-SET SWEDISH
  SET TRANSLATION INPUT \144 \64  ; What would normally be E-acute is atsign
  SET TRANSLATION INPUT \154 \94  ; U-diaeresis is circumflex
  SET TRANSLATION INPUT \129 \126 ; u-diaeresis is tilde
  SET TRANSLATION INPUT \130 \96  ; e-acute is accent grave
  SET TRANSLATION INPUT ON        ; Enable translation

Translations depend on the current code page, and Kermit asks DOS for this
information.  Code pages exist which are not distributed in the USA, such as
CP861 for Icelandic and CP862 for Hebrew.  It is said that DOS incorrectly
reports these code pages to be CP437.  It's not clear what the DOS code page
reporting mechanism would be, if any, for otherwise IBM-compatible PCs fitted
with special character sets such as Cyrillic, Arabic, etc, so in these cases
Kermit assumes CP437 and again, there is no method for the user to load the
necessary character set translation tables for file transfer.

Code page switching is reportedly not possible on old PC/ATs with small-memory
(64K) EGA boards, nor with DOS versions earlier than 3.30.

In MS-DOS Kermit 3.0 and 3.01, the right hand portion (GRight) of the Latin1
terminal character set won't be accessed by SI/SO locking shifts unless Kermit
first receives the escape sequence ESC-A (Escape, dash, uppercase A) from the
host.  This is the way Digital Equipment Corporation designed the VT300
terminals.  The initial state is G0 = G1 = ASCII, G2 = G3 = Latin1, and SI
(Control-N) shifts the GLeft pointer from the G0 to the G1 set.  The escape
sequence ESC-A puts Latin in G1.  Alternatively, the right hand portion is
accessable by using Single Shift 2, ESC N, or Locking Shift 2, ESC n, before
the text character(s).

In MS-DOS Kermit 3.10 and later, you can also designate Latin-1 to G1 (so that
SO/SI will work) by hand with the MS-DOS Kermit command:

  SET TERMINAL CHARACTER-SET LATIN1 G1

Kermit's terminal emulator sends characters with their 8th bit set as ESC N
<character without the high bit> if parity is other than NONE (version 3.12
has extended this mechanism; see MSR312.UPD).

LOG SESSION records the characters that arrive at the serial port, before
translation by either Kermit's built-in terminal character set translation
tables or by user-specified SET TRANSLATION INPUT commands (versions 2.32/A and
earlier did apply the SET TRANSLATION INPUT command before logging to disk).
This allows the REPLAY command to work correctly, but it prevents special
characters from being logged after translation to the PC's own character set.
Screen dump (Ctrl-End or Ctrl-]F) and autoprint, however, record the translated
characters.

SET TERMINAL CHARACTER SET is effective only for text screens, not for graphics
screens.  This is because the fonts for all the special characters have not
been designed yet (and may never be, and even if they are, they would require a
lot of memory).

International characters in macro names are not case independent.

Case-independent string matching operations (e.g. SET INPUT CASE IGNORE,
IF EQUAL xxx yyy) won't necessarily work with international characters.

COMMAND PROCESSING

A command file that contains lines or commands that are too long for DOS's line
buffer (usually 128 characters) can hang your PC.

The maximum size for a Kermit prompt string (SET PROMPT) is 60 characters.
However, Kermit does not complain if you use a longer one.  A work buffer is
overwritten, but the next time it is used, the effect on your prompt is
unpredictable.  (Fixed in 3.12)

Question-mark help is not available while typing a numeric field.

Commands in TAKE-files or MSKERMIT.INI can be continued by including "-" as the
last character on the line, but NOT if the line ends with a trailing comment.
In other words, you can't have a trailing comment on a continued line.  If you
need to end a line with a dash, but this dash is to be part of the command
rather than a continuation symbol, then use \45 instead or add a trailing
comment.

Trailing comments can be used only in command files.  All text starting with
the first semicolon through the end of line is ignored.  If you need to include
an actual semicolon in a command, precede with a backslash (\;).

The name and password that you specify in SET SERVER LOGIN must be matched
exactly by the ones in REMOTE LOGIN.  Alphabetic case matters.  If you need to
include spaces within the username, password, or account field of the REMOTE
LOGIN or SET SERVER LOGIN commands, surround the field with {braces}.

FILE TRANSFER

MS-DOS Kermit does not create zero-length files.  If a zero-length file is sent
to MS-DOS Kermit, it will not be created on your PC's disk.

SET EOF CTRL-Z, when used with text files which actually contain Ctrl-Zs, might
result in gaps or truncation in the vicinity of the Ctrl-Z.  This is a DOS
"feature".

When using Kermit through a terminal server (particularly those that execute
the TCP/IP Telnet protocol), or directly through a SET PORT TCP connection, it
is sometimes necessary to SET PARITY SPACE in order to transfer files.  It is
sometimes impossible to use very long packets with terminal servers.  Try SET
RECEIVE PACKET-LENGTH 80, working up or down to the longest length that works.

REMOTE TYPE and other REMOTE commands resulting in an error "Unable to open
CON": insufficient FILES= in CONFIG.SYS.  FILES= should be at least 20.

MS-DOS Kermit uses the program named in the DOS Environment command line
starting as SHELL= as a replacement for COMMAND.COM.  Such a line is seen by
typing SET at the DOS prompt, and it is not associated with the SHELL= line
appearing in file CONFIG.SYS.

The MS-DOS Kermit command REMOTE SET BLOCK-CHECK will generally have no effect
upon a remote server.  SET BLOCK-CHECK locally within MS-DOS Kermit.

The host prompt for TRANSMIT is a single character (SET TRANSMIT PROMPT).  It
is not possible to specify a multi-character or variable prompt.

SCRIPT PROGRAMMING

The terminal emulator is not active during execution of script commands such
as INPUT and OUTPUT.  This means:

 1. If the host sends the escape sequence that tells the terminal to identify
    itself, it is ignored.  You have to put the appropriate INPUT and OUTPUT
    commands in your script program.  Here is a macro to set your terminal type
    in Kermit and to set up the appropriate response string as well as terminal
    type string:

    def term if not def \%1 def \%1 vt320,-
     set term type \%1,-
     if error end 1,-
     assign _ttype \%1,-
     if eq \%1 vt320 assi _tid \27[\63\;1\;2\;4\;8\;9\;15c,-
     if eq \%1 vt220 assi _tid \27[\62\;1\;2\;4\;8\;9\;15c,-
     if eq \%1 vt102 assi _tid \27[\63\;6c,-
     if eq \%1 vt100 assi _tid \27[\63\;1c,-
     if eq \%1 vt52  assi _tid \27/Z

    Whenever you switch terminal emulations, do "term vt102" instead of "set
    term type vt102" (substitute your preferred terminal type).  In any script
    that responds to ESC Z (or whatever), have it "output \m(_tid)", and any
    prompt that asks for your terminal type you can "output \m(_ttype)".  And
    be sure to execute a "term" command in your MSKERMIT.INI file, so your
    initial terminal type is set.

 2. A host-generated escape to put the terminal in Tektronix mode has no
    effect.  Put explicit SET TERMINAL TYPE TEK commands in the appropriate
    places in your script program.

 3. Screen formatting escape sequences have no effect.  If you have SET INPUT
    ECHO ON, they are simply displayed as-is.

If the remote host is sending ANSI (VTxxx) escape sequences during execution of
the script program, then users of IBM PCs can use the ANSI.SYS or similar
console driver to interpret the escape sequences.  This is particularly useful
when running a script that logs in to a full-screen system, such as an IBM
mainframe through a protocol converter.  But beware: ANSI.SYS is not totally
compatible with Kermit's VT emulator, and it may produce unwanted side effects,
the most annoying of which is suddenly popping your PC into 40-column mode!  If
you experience difficulties with your screen display while using Kermit script
programs, use SET INPUT ECHO OFF.  Or remove ANSI.SYS from your CONFIG.SYS file
and reboot.

PAUSE, WAIT, and similar commands also cause port input to be echoed to the
screen if INPUT ECHO is ON.  Use SET INPUT ECHO OFF to defeat this effect.

Script programming hint: To test whether a readable floppy disk is available
in drive A:, do this:

  SPACE A:
  IF FAILURE ECHO No diskette in drive A:.

The ON_EXIT macro is intended only for automatic execution when the MS-DOS
Kermit program exits.  It only works once, to prevent recursion (as would
happen, for example, if you put an EXIT command in your ON_EXIT definition).
If you invoke the ON_EXIT macro explicitly during a Kermit session, you won't
be able to use it again.

HARDWARE RELATED PROBLEMS

Do not use the QEMM v6 "Stealth (ST:M) optimization" with Kermit.  This
prevents Kermit from accessing your video board's BIOS memory and finding the
video board's signature, and therefore from determining the appropriate method
for switching between 80 and 132 columns.

There have been isolated reports that MS-DOS Kermit (3.11 as well as earlier
versions) crashes with "Divide Overflow" errors on certain 486-based machines
such as the AST Bravo 486.  This problem is currently unresolved.  Kermit is
known to work properly on the Dell 486, and it contains no instructions that
require any kind of processor higher than an 8086/8088.  Reportedly, this
problem is not specific to Kermit; Microsoft Windows is said to crash on the
same machine if the BIOS cache memory is enabled, but works OK (but about 3
times slower) if the cache is disabled.

MS-DOS Kermit does not necessarily work with all brands of internal modems,
particularly some of the built-in ones that come with laptop PCs from various
makers.  If you can't communicate satisfactorily through such a modem, you can
use the new command SET COM1 <address> [ <irq> ] (also SET COM2 .. COM4) to
identify the port's hardware address and interrupt request line number.  USE
THIS COMMAND WITH CAUTION, AS IT MIGHT INTERFERE WITH YOUR PC's NORMAL
OPERATION!  If all else fails, give the command SET PORT BIOS1 (or 2, etc) and
try again, to access the port through the system BIOS -- this is much slower
that direct hardware control by Kermit.  Kermit does work with most popular
brands of internal modem (such as the Hayes Smartmodem 1200B and 2400B), and
with all known external (ASCII, not Baudot) modems, both direct-connect and
acoustic.

When using a COM3 or COM4 port whose address and IRQ differ from Kermit's
defaults, be sure to issue the SET COM3 (or SET COM4) command before SET PORT
COM3 (or COM4).

Kermit does not work properly with revision C of the "built-in" (not
"internal") modem in the Toshiba T1600 laptop computer.  Revision F does not
have this problem.

Add-in CPU boards might not handle UART serial port details properly if the
UART is not directly part of the add-in cpu board.  One symptom will be Kermit
can send but not receive characters.  Try SET PORT BIOS1.

Reportedly MS-DOS 2.11 for Tandy 1200 machines has an internal problem if a
program opens device CON for output, as Kermit does for REMOTE commands.  The
symptom is cross linkage of files on the current disk.  This has not been noted
with other versions of MS-DOS 2.11.  Solution: upgrade to a more recent version
of DOS.

INTERACTIONS WITH DOS

On early (original motherboard & BIOS) PCs, and on systems that mimic them
(e.g. early Compaqs), the cursor may assume a strange shape upon return from
CONNECT mode.  This is caused by a bug in the early BIOS, which stored cursor
attributes incorrectly.  The PC Tech Journal article "The Dashed Cursor", by
Paul Pierce, PC Tech J., Dec. 1985, page 47, suggests the following fix:

code    segment public 'code'
        assume cs:code, ds:code, es:nothing
;
;       This program is set up to be made into a COM file
;
        org     100H
;
; First check for the monochrome adapter.
;
start:  int     11H             ; set ax = equipment flag
        and     al,30H          ; mask off all but video bits
        cmp     al,30H          ; test for monochrome adapter
        jne     exit            ; jump if not monochrome
;
; Now check for incorrect cursor mode returned from the Bios
;
        mov     ah,3            ; call bios to get cursor type
        int     10H             ;
        cmp     cx,0607H        ; check for invalid (color) type
        jne     exit            ; jump if not a bad value
;
; At this point we know that the monochrome adapter is in use and that the
; BIOS cursor mode is wrong.  Call the BIOS to fix the cursor type.
;
        mov     cx,080cH        ; use correct cursor type
        mov     ah,1            ; call bios to set it
        int     10H

exit:   mov     ah,0            ; exit back to DOS
        int     21H

code    ends
        end     start

A REMOTE HOST or similar command sent to an MS-DOS Kermit server can invoke the
DOS critical error handler, which issues its familiar "Abort, Ignore, Retry?"
message on its real screen, and is waiting for a response from its own real
keyboard, and so the server will no longer respond.  Kermit attempts to catch
many of these errors before DOS learns learns about them, but some cannot be
avoided (like disk i/o errors).

Interaction between MS-DOS Kermit and various terminate-and-stay-resident (TSR)
programs is necessarily unpredictable, depending upon how "well behaved" they
are.  Certain console, mouse, clock, or graphics drivers might interfere with
file transfer, for example the CMOSCLK.SYS driver on the PS/2 model 55SX.  If
TSR programs are interfering with Kermit (by taking over the timer or serial
port interrupts), you should remove them all from your AUTOEXEC.BAT or
CONFIG.SYS files, and then put them back one by one until you have identified
the one that's causing the problem.

Caution should be used when invoking certain TSR programs while PUSHed from
Kermit (e.g. using the PRINT command for the first time), as not all of these
programs observe proper etiquette for allocating and freeing memory, and more
importantly the TSRs will be loaded above Kermit into the middle of memory
where they may prevent large programs from loading later.

NETWORKS

Sending BREAK over network connections via SET PORT BIOS1 + Int 14h interceptor
may or may not work, depending upon the actual network and drivers in use.
Kermit uses the BREAK facility if the driver and network support it.

Symptom: PC no longer works after installing a network board.  Diagnosis: a
16-bit VGA display adapter is running in 16-bit mode.  Cure: Jumper it back to
8 bits and all should start working again.

PC-NFS prevents applications programs such as Kermit from creating a file in
the root directory of a PC-NFS disk drive.  When the applications program asks
if a particular file exists in the root, PC-NFS always responds with "volume
label present", whether or not the actual file is present.

SET PORT TELAPI performance is good with version 4 of Novell's LAN WorkPlace
for DOS but it is poor with version 3.5 because that older version sends each
Kermit byte in an individual packet.  (Should be fixed in 3.12)

The Interconnections TES product, which Kermit fully supports, has a fancy menu
that pops up if you type the TES "hot key", Alt-LeftShift-T.  Reportedly, this
pop-up menu interferes with the LK250 driver that is distributed with Kermit
(it works fine with regular IBM keyboards).  The LK250 driver uses a special
interrupt, and the TES menu program might not properly chain this interrupt.
The workaround is to use TES's text-mode menu, which Kermit brings up if you
type Alt-n during terminal emulation.

MS-DOS Kermit 3.11 LAT connections do not work with PATHWORKS 3.0.  They do
work, however, with PATHWORKS 2.0 and 4.0.  Workaround: for PATHWORKS 3.0, use
CTERM connections instead of LAT.  (Fixed in 3.12)

For DECnet/DOS (PATHWORKS) LAT connections, it is often necessary to tell the
LAT control program on the PC to reserve enough memory for all of the local LAT
host names.  By default, space for 16 names is allocated.  Increase your LAT
control program's memory allocation if you have more than 16 hosts on your
DECnet network.  Also, remove ALL permanent LAT names from your database and
let the network provide them (this can mean waiting a minute or two for all
broadcasts to be heard).

Connections via Kermit's built-in LAT support do not work when LAT is loaded
into EMS (expanded memory) under Microsoft Windows 3.0.  Load LAT into
conventional memory.  (Should be fixed in 3.12)

Reportedly, "set port decnet <node> <password>" doesn't work for LAT
connections when a password must be specified.


NETBIOS STATION-TO-STATION CONNECTIONS

The procedure for establishing a NETBIOS PC-to-PC connection is as follows:

 1. On the first PC:
      SET NETBIOS NAME <xxx>
      SET PORT NETBIOS
      SERVER

 2. On the second PC:
      SET PORT NETBIOS <xxx>.K

("<xxx>" is any name you choose, up to 14 characters in length.)

Now you can initiate file transfer and other Kermit protocol operations from
the second PC.  If you want the two PCs to "chat" in terminal mode, send a
FINISH command from the second PC (or type Ctrl-C on the first, server, PC),
and then give the following commands to both PCs:

  SET TERMINAL NEWLINE ON
  SET LOCAL-ECHO ON
  CONNECT

TCP/IP SUPPORT

As of version 3.11, MS-DOS Kermit contains built-in TCP/IP and TELNET protocol
support.  This allows a PC equipped with an Ethernet or other network board
that is connected to a TCP/IP network to communicate with any other node on
the network, without requiring any additional TCP/IP software on your PC.  You
need an external Ethernet-style (Class 1) packet driver for your network
interface board, or a SLIP Packet Driver, or a Novell ODI driver.  With ODI,
Kermit's Telnet operates across Ethernet (many frame kinds), Token Ring,
Arcnet, and PCnet.  Kermit does not contain built-in network device drivers.
Packet drivers are available from network interface manufacturers, and also
via anonymous FTP from Columbia University, host watsun.cc.columbia.edu
[128.59.39.2], cd packet-drivers, get the READ.ME file, read it, and take it
from there.  These files, now called the Crynwyr packet driver collection, are
also available from Columbia University via mail order.  ODI drivers are
available from makers of the LAN adapter and in some cases from Novell.  See
Novell archive "novlib" on Compuserve and on machines ftp.is.sandy.novell.com
[137.65.12.2] and mirrors such as netlab2.usu.edu [129.123.1.44] for Novell
supplied ODI drivers.

The TCP/IP code in this version of Kermit has been tested successfully with
the following boards and packet drivers (according to reports from users):

  Ungermann-Bass PC/NIC board with Clarkson UBNICPC packet driver 9.1
  3COM 3C501 with Clarkson 3C501 packet driver 5.0.
  3COM 3C503 with Clarkson 3C503 packet driver 9.4.0.
  Western Digital WD8003E with WD8003E packet driver 9.7.0
  Cabletron 2000 and 3000 series DNI boards with CSIPD_E 1.0x packet
    drivers on unshielded twisted pair, thin Ethernet, and thick Ethernet,
    on both PC/AT and Microchannel buses (don't use CSIPD_X 2.00).
  Micom-Racal NI5210 with NI5210 packet driver.
  AT&T EN100 with Clarkson AT&T packet driver.
  IBMTOKEN.COM 3C501 emulation packet driver 1.9 over various Token Ring
    boards and drivers.
  DIS_PKT over NDIS for LAN Manager networks and NDIS-compliant boards
    including SD8003, 3C503, AT&T 10MB/sec thinwire
  Harvard ODIPKT over LSL, LANSUP, and IPXODI over Ethernet (but not
    Token Ring)

LocalTalk packet drivers are not supported, as they are not Ethernet-class
Packet drivers.  SLIP is supported in Version 3.12.

The performance of the 3C50x packet drivers is poor, but the operation seems
correct.  Suggestion from a 3COM 3C503 Ethernet board user: "When installing
the packet driver for 3Com 503 cards, one has to pay attention that the memory
option on the card is not disabled.  It was in my case, and the packet-driver
did not complain.  Since other drivers (e.g.  the DEC PATHWORKS driver) do not
require the memory enabled, the default is disabled."

Reportedly, the packet driver supplied by Western Digital with their WD8003E
and/or Elite network boards cannot be found by Kermit.  The Crynwyr WD8003E
packet driver, however, works correctly with both the WD8003E and Elite boards.

To reconfigure a Novell network for packet drivers so Kermit and Novell
software can be used concurrently, use special software developed at Brigham
Young University, available via anonymous ftp from dcsprod.byu.edu.  For
further information, read the Kermit Distribution file MSABYU.HLP.

An Ethernet-simulation packet driver is available for systems using the NDIS
(Network Driver Interface Specification) program.  NDIS is frequently used with
Lan Manager networks, including AT&T's StarGROUP network and DEC's Pathworks
for DOS.  The interface program is named DIS_PKT and originated with FTP
Software Inc.  Their program DIS_PKT.GUP is available by anonymous ftp to
vax.ftp.com, and a research version DIS_PKT9.ZIP is available from Utah State
University by anonymous ftp to netlab2.usu.edu.  Instructions for configuring
Lan Manager to include DIS_PKT are included with the program.

Kermit's TCP/IP support does not work over the Harvard ODIPKT driver on a Token
Ring network because it requires Kermit to use Token Ring rather than Ethernet
frames (but it does work with ODIPKT over Ethernet).  Version 3.12 supports
ODI directly, ODIPKT is not necessary except when using Windows.

Direct use of ODI drivers permits Kermit's TCP/IP to run with several kinds of
Ethernet frames: DIX/Blue-Book/Ethernet_II, 802.2, 802.2 with SNAP, and 802.3,
as well as with Token Ring, Arcnet, and PCLan broadband.  No extra protocol
"shim" is needed.  The ODI interface will be tried if a Packet Driver is not
found, and it can be selected in preference to a packet driver by the command:

   SET TCP/IP PACKET-DRIVER-INTERRUPT ODI

where "ODI" replaces the interrupt number of a Packet Driver.

For ODI, the file NET.CFG should have the lines "Protocol IP etc" similar to
the example below:

    # File NET.CFG, example
    PB buffers=10
    show dots=on

    Link Support
        buffers 6 1514
        MemPool 2048

    Link Driver SMCPLUS
        Port  280 20
        Mem   000CA000 2000/10
        Int   7
        frame Ethernet_II
        Protocol IPX    8137    Ethernet_II
        Protocol IP    0800    Ethernet_II
        Protocol ARP    0806    Ethernet_II
        Protocol RARP    8035    Ethernet_II

Kermit requires three "protocols", IP, ARP, and optionally RARP as shown
above.  The frame kinds can be anything the board will support: Ethernet,
Token Ring, Arcnet, all IEEE 802.2-based frames etc.  ODI will complain if the
frame type cannot support these protocols.  Arcnet uses different TYPE values,
D4 for IP, D5 for ARP, and D6 for RARP, rather than 0800 etc, as per RFC-1201.

There is the question of which board Kermit (or IPX or other application) will
use if two or more boards are available.  Although one would think the board
could be selected by placing the Protocol IP, etc, lines under the desired
Link Driver section, such is not really the case; those lines tell the LSL the
frame kind to associate with the protocol (say IP) but not the board.  The
frame lines are associated with particular boards, however.  The default
method for finding a board is that the application chooses "the first board"
offering a suitable frame, regardless of whether or not the Protocol IP, etc,
lines are present for that board.  "First" refers not to the contents of
NET.CFG but to the order in which board drivers are loaded at DOS level.  So
the indented protocol lines tell ODI which frame a protocol needs, and a TYPE
to use for recognizing packets, but the lines do not identify a particular
board.

To target a particular board a separate main section is used in NET.CFG.  The
section starts with the word Protocol against the left margin and has Bind
indented beneath it, like this -

       Protocol Kermit            indentifies Kermit section of NET.CFG
        bind SMCPLUS        bind to SMCPLUS board driver

When a board name is used more than once then the alternative form is to use
a board number in place of the name:

       Protocol Kermit
        bind #2            bind to the board loaded second

Kermit considers the text in these sections to be case insensitive.  The
#<digit> construction must not have a separation between the number sign (#)
and the digit.  The #<digit> case is normally used when two or more boards
share the same driver and thus are not distinguishable by name alone.

A sample STARTNET.BAT file might look like this.

@echo off            run quietly
c:\lsl >nul            LSL is always loaded before boards
c:\smcplus.com >nul        SMC/WD8003E board, the first
c:\exos.com >nul        EXOS-205T board, the second
rem c:\odinsup            Odinsup can coexist with Kermit
rem c:\odipkt 0 96        Odipkt can coexist with Kermit
c:\ipxodi >nul            IPX is always loaded after boards
rem echo Starting network...    may be needed to help some drivers
c:\bnetx ps=my-preferred-server > nul
rem (Packet Burst mode)    NETX loads after IPX
@echo on

If both EXOS and SMCPLUS boards offer frame Ethernet_II Kermit will choose the
first loaded board, SMCPLUS, in the absence of a "bind" command.  Putting the
section "Protocol Kermit, bind <board name or number>" anywhere in NET.CFG
selects a particular board for Kermit.  A complete NET.CFG file using two
boards is shown below:

# File NET.CFG, an example with two boards
PB buffers=10
show dots=on
# all main sections must start in column 1, indent local material.

# Protocol "IPX" is for Novell's IPXODI
Protocol IPX
    Bind EXOS

# Protocol "Kermit" is for MS-DOS Kermit
Protocol KERMIT
    Bind EXOS

Link Support
    buffers 6 1514
    MemPool 2048

Link Driver exos
    Port  310 20
    Mem   000D0000 400
    Int   5
    frame Ethernet_II
    Protocol IPX    8137    Ethernet_II
    Protocol IP    0800    Ethernet_II
    Protocol ARP    0806    Ethernet_II
    Protocol RARP    8035    Ethernet_II

Link Driver SMCPLUS
    Port  280 20
    Mem   000CA000 2000/10
    Int   7
    frame Ethernet_II
    frame Ethernet_Snap
    Protocol IPX    8137    Ethernet_II
    Protocol IP    0800    Ethernet_II
    Protocol ARP    0806    Ethernet_II
    Protocol RARP    8035    Ethernet_II

# Protocol "TCPIP" is for Novell's Lan WorkPlace for DOS, not Kermit
Protocol TCPIP
    ip_address    129.123.1.99
    ip_router    129.123.1.254
    ip_netmask    255.255.255.0
    tcp_sockets    8
    udp_sockets    8
    raw_sockets    1
    nb_sessions    4
    nb_commands    8
    nb_adapter    0
    nb_domain    usu.edu

At the moment there is no Windows support for Kermit over ODI.

Kermit's built-in TCP/IP support in v3.11, as well as several other of its
networking methods, use BIOS Int 14H internally.  This can interfere with
other devices whose drivers use the same interrupt, for example speech
devices connected to a serial port.  Version 3.12 avoids this problem.

Domain name resolution might not work when you give a nickname instead of a
complete host name in the SET PORT TCP/IP command and Kermit transforms
the nickname into the desired complete host name by combining it with your
TCP/IP DOMAIN.  Notice that Kermit does not use a special Hosts file to relate
nicknames to complete host names.  Workarounds: use a complete hostname, an IP
host number, or set your TCP/IP DOMAIN correctly.  It should be obvious that
Domain Name Servers are specified by their IP number rather than name.

Version 3.12 supports multiple gateways off the local network.  Choosing the
incorrect gateway normally results in that gateway sending an ICMP Redirect
message to Kermit indicating the preferred gateway, and Kermit displays such
messages.  Version 3.11 did not implement ICMP Redirect actions.

For IBM mainframe linemode connections, automatic appearance of the login
banner might not work.  Type a carriage return (Enter) to get the login
banner.  Local-echo and linemode operation are negotiated automatically.

BOOTP requests are handled correctly within the local network, and have been
tested successfully through Novell's BOOTP forwarder NLM and through Cisco
routers with software version 8.2.7.  In the SET TCP/IP ADDRESS command, the
words BOOTP and RARP must be spelled out in full.

EXIT from Kermit closes your TCP/IP session (just like HANGUP).  PUSHing or
running DOS commands from Kermit keeps it open.  In version 3.12, EXITing
while a session is active causes a confirmation message to appear, so you can
change your mind.

Kermit can connect to any TCP port other than SMTP (25, mail), but version
3.11 uses only TELNET port (23).  Kermit honors TELNET protocol negotiations,
including terminal type and ECHO/SGA.  Version 3.11 sends "VT100"; version
3.12 sends the active terminal type or allows the user to create a string with
command SET TCP/IP TELNET-TERM-TYPE.

TELNET protocol echo negotiations do not work with certain hosts, protocol
converters, or terminal servers.  Some examples include Xyplex terminal
servers, MICOM Interlan NTS100 terminal servers, MVS/TSO systems accessed via
Fibronics KNET/MVS 3.0, Network Research Corp's TCP/IP for VAX/VMS.  (This
should be fixed in version 3.12).  TELNET options are often implemented
strangely on terminal servers, so beware.

Not supported: FTP, TFTP, multiple sessions, automatic setting of PC date/time
from network, 3270 emulation (tn3270), etc.  There is no PING command, but
MS-DOS Kermit responds when PINGed and when probed by Traceoute.  The
keyboard verb \Knethold does nothing.

For TCP/IP connections to IBM mainframes in full screen 3270 mode, you need an
intermediate host or device to do the 3270/ASCII terminal conversion.  Typical
setup is a TCP/IP terminal server with its serial lines connected to a protocol
converter (e.g. IBM 7171), a UNIX host that has tn3270 available, or a terminal
server (like Cisco) that does 3270 terminal emulation.  To transfer files with
an IBM mainframe, you might have to tell MS-DOS Kermit to SET PARITY SPACE.

Version 3.12 supports inbound connections to MS-DOS Kermit but version 3.11
does not.  Inbound TELNET connections do not copy DOS screens, etc, in the
manner of products such as Carbon Copy and PC Anywhere and the free telnetd
program of Erick Engelke; a Kermit-to-Kermit connection is made instead.

MS-DOS Kermit does not provide any services except PING, i.e. ICMP ECHO,
and Traceroute replies to outside requestors.  You can't "finger" it, mail to
it, etc.

Kermit's TCP/IP support cannot be used simultaneously with PC NFS because both
applications want to register use of ARP, IP, and other protocols with the
packet driver, but each protocol can only be assigned to one application.
This is only one particular case of the more general rule: only one TCP/IP
based application can use a LAN adapter at once.

To make Kermit TCP/IP connections under Windows 3.0 (Enhanced Mode), configure
its .PIF file to "Lock Application in Memory", or preferably use the WINPKT
shim.  Only one copy of Kermit can have a TCP/IP connection at a time.

The SET TCP/IP and SET PORT TCP/IP commands only return failure codes if there
is a parse error.  The connection is not opened until the first attempt to
communicate with the remote host: CONNECT, PAUSE, OUTPUT, etc.  While
connection establishment is in progress, you can't interrupt the program with
Ctrl-C.  Use IF SUCCESS / FAILURE after PAUSE 0 to check if the connection
is open, for example:

  DEFINE TELNET SET PORT TCP \%1 \%2, PAUSE 0, IF SUCCESS CONNECT

The second variable above is for the optional TCP port number in version 3.12.

Performance hints: Set your Kermit packet size to about 500, so it will fit
inside network packets, or to some multiple thereof.  A packet size of, say,
600 (or 1100, etc) gives poor performance, because the result on the net is a
long and a short packet.  A convenient setting is SET RECEIVE PACKET 2000, SET
WINDOW 4, resulting in four 500-byte packets in a window.  SET FLOW NONE lets
TCP/IP do the flow control and eliminates Kermit's need to check for Xon/Xoff.
In most situations beyond the local network performance will be limited by the
long distance lines rather than by the PC.

End of MSKERM.BWR / KERMIT.BWR